home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / dns / dns-minutes-93mar.txt < prev    next >
Text File  |  1993-04-28  |  13KB  |  292 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5.  
  6. Reported by Rob Austein/Epilogue Technology
  7.  
  8. Minutes of the Domain Name System Working Group (DNS)
  9.  
  10. The meeting opened with a few comments by the Chair regarding the future
  11. of the Working Group.  In brief, the Working Group has been in existence
  12. for a long time, with ill-defined goals and an odd mixture of tasks.
  13. Some of the Working Group's tasks are of an ongoing nature, some are
  14. very specific with definite goals and milestones.  As currently
  15. organized, the Working Group does not fit well into the IETF
  16. administrative structure.  At some point in the relatively near future
  17. it may be necessary to restructure the Group to address this problem.
  18. The Chair will be working with the Director of the new IETF Service
  19. Applications Area to address this issue.
  20.  
  21. Given the state of flux that the IESG and the IETF itself were in at the
  22. time of the Working Group meeting, the Working Group decided to spin off
  23. a few well-defined tasks to ``sub-groups'' but otherwise leave the
  24. current DNS Working Group structure unchanged.  Whether the
  25. ``sub-groups'' would be full-fledged IETF working groups or just
  26. subcommittees of the DNS Working Group was left unspecified; the
  27. organizers of the three sub-groups spun off at this meeting all
  28. subsequently expressed a distinct preference for being subcommittees
  29. rather than independent working groups.
  30.  
  31. The next item of business was to dispose of some old tasks that were
  32. still listed on the Group's Charter.  The following tasks were removed
  33. from the task list:
  34.  
  35.  
  36.   1. Discussion of adding a Responsible Person RR.
  37.   2. Discussion of adding network naming capability to the DNS.
  38.   3. Implementation catalogue for DNS software.
  39.   4. Writing a ``DNS operators guide''.
  40.  
  41.  
  42. Tasks (1) and (2) were done years ago and published in RFCs 1183 and
  43. 1101, respectively.  Task (3) was killed for lack of any volunteers who
  44. care about it enough to write it; if such a volunteer exists, that
  45. person should just write the document, we don't need a group effort to
  46. do this.
  47.  
  48. The Group also briefly discussed writing a ``DNS Operators guide'', Task
  49. (4).  Since both RFCs 1032-1033 and an O'Reilly Associates book exist on
  50. the subject, the Group felt that writing such a document would be a
  51. waste of time.  Stuart Vance agreed to write a one-page document
  52. referring readers to the O'Reilly Associates book; if there are other
  53. published documents on this subject, whether commercial or free, please
  54. announce them on the Namedroppers list for possible mention in Stuart's
  55. reference.
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63. Next on the Agenda were the three tasks that were felt by the Group to
  64. be of sufficient interest to form a subgroup to work on each task.  Each
  65. task was discussed for long enough to air some of the issues that needed
  66. to be addressed, then the Chair called for someone willing to organize a
  67. subgroup willing to attack the problem and report back.
  68.  
  69.  
  70.   1. Scaling problems of ``big zones'', particularly the .COM zone.
  71.      The Working Group has been kicking this problem around for a year
  72.      without much progress.  Discussion was limited to a summary of the
  73.      problem by Mike St.  Johns and to new suggestions by the Working
  74.      Group.  One-line summary:  some of the first-level DNS zones are
  75.      approaching the size of the old NIC HOSTS.TXT file, which leads to
  76.      various technical and political problems.  Please see the Minutes
  77.      of previous DNS Working Group meetings for background on this
  78.      discussion.
  79.      John Romkey pointed out that, as the Internet grows and more hosts
  80.      are registered in the DNS, it will be increasingly hard to maintain
  81.      any kind of obvious correlation between DNS names and ``real''
  82.      names.  All the proposed ``solutions'' to the .COM zone problem
  83.      will exacerbate this situation; the only exception is the
  84.      ``XYZCORP.X.COM'' partitioning scheme, which, while ugly, is at
  85.      least obvious.  In the long run we need a solution to the problem
  86.      of unintuitive names in the DNS. Whatever solution we pick for the
  87.      .COM zone should be chosen with this in mind, so that we don't make
  88.      the problem worse.
  89.      Bill Manning agreed to lead a subgroup to investigate the problem
  90.      and report back.  The subgroup's mailing list is ``bigz@rice.edu'',
  91.      send mail to ``bigz-request@rice.edu'' to join the list.
  92.  
  93.   2. DNS security.
  94.      The Working Group heard a report from Steve Crocker, Director of
  95.      the IETF Security Area.  There are really two tasks under
  96.      discussion.
  97.  
  98.      (a) The first security task is bulletproofing the DNS so that it
  99.          cannot be spoofed without ability to spoof IP addresses; this
  100.          is, essentially, Paul Mockapetris's ``Just As Good As IP''
  101.          security mechanism, as described by Paul at the ``DNS-II'' BOF
  102.          held at the 25th IETF in Washington DC. This level of security
  103.          could also be described as ``robustness,'' that is,
  104.          implementation of Paul's techniques would help defend the
  105.          global DNS database against some of the accidental spoofing
  106.          that has happened over the years.  This is primarily an
  107.          implementation issue, and wheels are already rolling to get
  108.          this mechanism into a near-future release of BIND. Watch the
  109.          namedroppers list for announcements.
  110.  
  111.      (b) The second security task is specifying a mechanism by which RRs
  112.          could be accompanied by digital signature information for
  113.          authentication.  Both for backwards compatibility with existing
  114.          DNS software and in order to avoid running afoul of U.S. export
  115.  
  116.                                    2
  117.  
  118.  
  119.  
  120.  
  121.  
  122.          controls on cryptographic software, this signature must be an
  123.          optional mechanism, added in such a way that non-players can
  124.          ignore it and still comply with the DNS protocols.  The general
  125.          idea is to define a new RR type, the RDATA portion of which
  126.          would be used to contain the digital signature.  James Galvin
  127.          agreed to lead a subgroup to work on this project and report
  128.          back to the Working Group.  The subgroup's mailing list is
  129.          ``dns-security@tis.com'', send mail to
  130.          ``dns-security-request@tis.com'' to join the list.
  131.  
  132.  
  133.   3. Load balancing.
  134.      This task has been with the Working Group for a long time.  At the
  135.      time of this meeting there were at least four mechanisms proposed
  136.      to solve some aspect of the ``load balancing'' problem, some
  137.      already in widespread use, one requiring no protocol changes at
  138.      all.  Tom Brisco and Stuart Vance agreed to lead a subgroup to
  139.      investigate this problem and document their conclusions.  The
  140.      subgroup's mailing list is ``dns-wg-lb@ns1.rutgers.edu'', send mail
  141.      to ``dns-wg-lb-request@ns1.rutgers.edu'' to join the list.
  142.  
  143.  
  144. Next, the Working Group heard a report on the current status of the DNS
  145. MIB from Frank Kastenholz, representing the IETF Network Management
  146. Directorate.  In brief, the DNS MIB has been stalled since the 25th IETF
  147. for two reasons:
  148.  
  149.  
  150.   1. The Network Management Area Directorate has been busy with the
  151.      emerging SNMPv2 specification and suffered some disorganization due
  152.      to the abrupt resignation of its Area Director, and
  153.  
  154.   2. The DNS MIB presents some non-trivial problems, because there are
  155.      some cases where the ``SNMP way'' and the ``DNS way'' of doing
  156.      things are diametrically opposed.
  157.  
  158.  
  159. Problem (1) is already being repaired:  a new Area Director for Network
  160. Management was elected two days after the DNS Working Group meeting, and
  161. the SNMPv2 specification is on its way out the door.
  162.  
  163. Problem (2) will be addressed by Frank (representing the Network
  164. Management Area Directorate) and the authors of the DNS MIB.
  165.  
  166. Frank suggested that the DNS Working Group consider whether or not SNMP
  167. was really the right tool for all of the management tasks addressed by
  168. the DNS MIB, and for the proposed dynamic update mechanism (dynamic
  169. creation and deletion of RRs via a network protocol); it's possible that
  170. extensions to the DNS protocol might be more appropriate for some of
  171. these tasks.  James Galvin pointed out a counter-argument:  if DNS
  172. management is not done via SNMP, the extended DNS protocol would need to
  173. duplicate much of the mechanism of SNMP, including the security
  174. features.  The Working Group decided to press ahead with cleaning up the
  175.  
  176.                                    3
  177.  
  178.  
  179.  
  180.  
  181.  
  182. DNS MIB, given that we've already spent so much time on it.
  183.  
  184. Next, Susan Thomson gave a presentation on DNS support for PIP. The
  185. presentation was basicly the same material covered in the PIP-DNS
  186. Internet-Draft (``draft-ietf-pip-dns-00.txt'').  The Group discussed
  187. three problems with the PIP-DNS proposal:
  188.  
  189.  
  190.   1. The PIP-DNS proposal creates two new semi-wildcard QTYPEs (the PIP
  191.      document calls these ``special-purpose query types'').
  192.      Semi-wildcard QTYPEs have known problems when combined with DNS
  193.      caching algorithms, as documented in RFC-973, page 4, ``MD and MF
  194.      replaced by MX''. The Working Group recommended that the PIP Group
  195.      redesign their proposal to get rid of the semi-wildcard QTYPEs.
  196.  
  197.   2. The proposed BBD (BackBone Descriptor) RR format defined a
  198.      one-octet field to select the character set used in the variable
  199.      length text portions of the RR. The Working Group recommended that
  200.      this be eliminated and that the variable length text portions of
  201.      the RR be limited to the NETASCII character set.
  202.  
  203.   3. PIP includes a mechanism by which a PIP implementation can know
  204.      that it needs to get a fresh copy of an RR. The PIP implementors
  205.      would like to have a way to speed propagation of fresh information
  206.      when this happens.  Discussion of this subject on the Namedroppers
  207.      list suggests that one way to accomplish this would be the addition
  208.      of an RR timestamping mechanism to the DNS. To date we do not know
  209.      how to add such timestamps without an incompatible change to the
  210.      DNS protocols, so we may not be able to help the PIP implementors
  211.      here.  This issue was left open, due to time pressure at the
  212.      Working Group meeting.
  213.  
  214.  
  215. There was a brief discussion of the proposed X.400 ``temporary'' routing
  216. mechanism (using the DNS to replace X.400 routing tables).  Those
  217. members of the Working Group who had read the proposal felt that it was
  218. seriously flawed and could not be implemented as specified.  Rob Austein
  219. and Jon Postel volunteered to meet with the authors of the proposal in
  220. order to find the right answer to this problem.  Said meeting took place
  221. two days later, and resulted in a better solution, to be documented by
  222. Claudio Allocchio, one of the authors of the original proposal.
  223.  
  224. At this point, having run out of time and having covered all the major
  225. items on the Agenda, the meeting was adjourned.
  226.  
  227. Attendees
  228.  
  229. N. Akiko Aizawa          akiko@nacsis.ac.jp
  230. Philip Almquist          almquist@jessica.stanford.edu
  231. Randall Atkinson         atkinson@itd.nrl.navy.mil
  232. Robert Austein           sra@epilogue.com
  233. David Battle             battle@cs.utk.edu
  234. David Bolen              db3l@ans.net
  235.  
  236.                                    4
  237.  
  238.  
  239.  
  240.  
  241.  
  242. Erik-Jan Bos             erik-jan.bos@surfnet.nl
  243. David Bridgham           dab@epilogue.com
  244. Thomas Brisco            brisco@pilot.njin.net
  245. Sandy Bryant             slb@virginia.edu
  246. Henry Clark              henryc@oar.net
  247. Wayne Clark              wclark@cisco.com
  248. David Conklin            conklin@jvnc.net
  249. Stephen Crocker          crocker@tis.com
  250. John Curran              jcurran@nic.near.net
  251. Chas DiFatta             chas@cmu.edu
  252. James Galvin             galvin@tis.com
  253. Richard Graveman         rfg@ctt.bellcore.com
  254. Steven Hubert            hubert@cac.washington.edu
  255. Daniel Karrenberg        daniel@ripe.net
  256. Frank Kastenholz         kasten@ftp.com
  257. David Katinsky           dmk@pilot.njin.net
  258. Kenneth Key              key@cs.utk.edu
  259. John Klensin             klensin@infoods.unu.edu
  260. John Linn                linn@gza.com
  261. Daniel Long              long@nic.near.net
  262. Steven Lunt              lunt@bellcore.com
  263. Paul Lustgraaf           grpjl@iastate.edu
  264. Bruce Mackey             brucem@cinops.xerox.com
  265. Bill Manning             bmanning@sesqui.net
  266. Clifford Neuman          bcn@isi.edu
  267. William Nowicki          nowicki@legato.com
  268. Masataka Ohta            mohta@cc.titech.ac.jp
  269. Andrew Partan            asp@uunet.uu.net
  270. Brad Passwaters          bjp@sura.net
  271. Michael Patton           map@bbn.com
  272. John Penners             jpenners@advtech.uswest.com
  273. Jon Postel               postel@isi.edu
  274. Robert Reschly           reschly@brl.mil
  275. John Romkey              romkey@asylum.sf.ca.us
  276. Jon Saperia              saperia@lkg.dec.com
  277. Carl Schoeneberger       70410.3563@Compuserve.com
  278. Tim Seaver               tas@concert.net
  279. Allyson Showalter        allyson@nsipo.arc.nasa.gov
  280. Michael St.  Johns       stjohns@darpa.mil
  281. Martha Steenstrup        msteenst@bbn.com
  282. Bernhard Stockman        boss@ebone.net
  283. Susan Thomson            set@bellcore.com
  284. L. Stuart Vance          vance@tgv.com
  285. Ruediger Volk            rv@informatik.uni-dortmund.de
  286. Chuck Warlick            warlick@theophilis.nsfc.nasa.gov
  287. Jane Wojcik              jwojcik@bbn.com
  288.  
  289.  
  290.  
  291.                                    5
  292.